情報 -> Python
Pythonの諸々に関するメモ
内部ライブラリ
socket
研究開発程度の規模でIoT開発を行うなら、socketなどの低レイヤ通信で十分なことも（アプリケーション層でやり取りする場合はHTTPかMQTT）
multiprocessing
高速化のメイン手段
メイン処理を関数にまとめる必要があるので、モジュール化の癖をつけたりif __name__ == __main__でくくる癖をつけたりしておくと移行がめんどくさくなりにくい
外部ライブラリ
numpy
n次元配列を扱うときに必須
int16/int32やfloat32/float64など、整数型や小数型にも種類がある numpyだけなら問題にならないが、pytorchなどの機械学習ライブラリを用いる際にエラーが出ることがあるため、特に動的型付けに慣れている場合は要注意
pandas
DataFrameがCSV/SQLと変換しやすく便利 ただ激遅
for index row in df.iterrows()を使いがちだが、慣れてきたらdf.apply(lambda x: )を使った方が良い 可読性の面でも速度の面でも後者の方が有利
欠損値(None)は思わぬエラーにつながる 可変長のものを扱うならdict型等も検討するべき
matplotlib
勝手にメモリリークしがち 多数の描画を行う際はmatplotlib.use("Agg")を指定 （あとplt.close()も忘れずに）
plotをfor文で回すと遅くなる・描画は全体的に遅い
plt.savefig()を大量に呼び出す場合は画像拡張子を非圧縮の.tiff等に設定するとやや速い
seaborn
pairplotで各変数間の相関を確認する際に便利
flask
render_templateで全てを構築しようとすると大変なことになるので、早々にフロントエンドと切り分けた方が良い
APIとして使う程度にとどめてHTML/CSS/JSファイルをフロントエンド側にまとめるとディレクトリ構成が分かりやすくなる
tqdm
計算時間の長いプログラムを動かす際、簡単に残り時間予測を出せるので便利
外部ライブラリ（機械学習系）
scikit-learn
クラスを入れ替えれば簡単に別の解析手法が試せる
pytorch
DNNを行うときtensorflow.kerasよりカスタマイズしやすい
CUDAの設定方法がデバイス毎・ツール毎に微妙に異なりやや面倒 ただ絶対設定した方が良い
optuna
ハイパーパラメータの自動探索に使える
scipy
カーブフィッティングなどに使える
gymnasium
強化学習用のモデルを作成するライブラリ gymを使うとFutureWarningが出るので、素直に後継のgymnasiumを使うのが良い
stable_baselines
強化学習を行うライブラリ scikit-learnと同じくクラスの入れ替えで簡単に別のアルゴリズムが使えて便利
その他
AIの使用
学生ならGithub Copilotが超便利 スニペットを呼び出すまでもなく入力を補完してくれる
通常のChatGPTも超便利 ただ自分のコードの把握が追い付かないことも多いので、必ず生成されたものは関数やモジュールとして独立させ、エラーが出たときにどのチャットログに修正依頼を出せば良いか整理しておく
ロバスト性の確保
長時間動かすプログラムはtry: except Exception as e:を書いておいて損なし 特に外部サービスと連携する場合は必ず何かしらの例外処理を書く
型は割と柔軟に対応してくれるが、np.NaNとNoneはエラーが出がち
異常値が出ない前提なら早めにassertで検出した方が良い
異常値を異常値として渡したい場合はどのような形式で渡されるかを明示的に記述する
動的型付けが嫌いなら適宜明示的な型変換や型ヒントの利用を行う
動的型付けもさることながら、ネスト内で定義した変数をネストの外で使用できるため、初期化漏れが起こりがち var = 1 if isA else 0のように、条件式をブール変数にまとめて三項演算子を使うなどで対策する
プロファイリング
上述の通り時間的なボトルネックが大量に存在するので、少しでも遅いと思ったらcProfileでプロファイリングをした方が良い
外部ライブラリをあまり使わないのであればPyPyやCythonなどの環境を組んでも良い（ただそれをする知識があるのならC++とかを学んだ方が速いかも）
デバッグ
VSCodeのデバッグ機能さえおさえておけば十分（なはず）
条件付きブレークポイントが強力なので、print()でデバッグをするのがベストなケースはほとんど無いと思った方が良い
可読性
Pythonはネストが深くなるとインデントのせいで非常に見栄えが悪くなる
→早期リターンの徹底 早期リターンを行おうとすることで自然と単一責任原則も満たされる
個人開発でもGitHubを使うと「またいつか使うかもしれないコード」を臆せず削除できる コミットの際には必ず「delete ○○」と記載するほか、前もって何パターンか作ることが想定される場合は早めにブランチを切る（後でマージするのは簡単）
ただgitignoreの範囲に注意
オブジェクト指向
正直純オブジェクト指向言語に比べて取り回しは微妙だが、コードの規模が大きくなっていくとクラスを使った方が読みやすくなる